Conversation
This comment was marked as outdated.
This comment was marked as outdated.
| #[derive(Deserialize, Debug)] | ||
| pub struct OrganizationDetails { | ||
| pub id: String, | ||
| pub links: OrganizationLinks, |
There was a problem hiding this comment.
This endpoint has a bunch more information but what we really care about is the id and links.
The region_url contains the regional API url, e.g. us.sentry.io. This way we can hit that endpoint directly instead of going through control silo (sentry.io).
If I understand correctly I think this information might already be somehow embedded in org tokens, but not in personal tokens. Or maybe I'm confusing this with something else.
There was a problem hiding this comment.
If I understand correctly I think this information might already be somehow embedded in org tokens, but not in personal tokens
This is 100% correct
There was a problem hiding this comment.
Ok then I should see how to resolve the id from the token instead of using the API call when we have an org token.
There was a problem hiding this comment.
To clarify, only the region URL is embedded. Org ID is not
There was a problem hiding this comment.
Let's discuss about the need to resolve the org and project IDs in the first place. Almost all other endpoints are capable of accepting both slugs and IDs interchangeably in the backend (Sentry side). To me it seems like a pretty serious limitation if objectstore cannot accept either.
That said, what you mentioned about having arbitrary keys in your other comment makes sense, and I guess it makes it harder to accept both IDs and slugs. Let's see if we can come up with a solution here, though
| use anyhow::{Context, Result}; | ||
|
|
||
| /// Given an org and project slugs or IDs, returns the IDs of both. | ||
| pub fn get_org_project_id(api: impl AsRef<Api>, org: &str, project: &str) -> Result<(u64, u64)> { |
There was a problem hiding this comment.
As far as I know, for all commands a user can provide --project and --org as slugs or IDs.
These utils are needed to get the corresponding IDs, so that objects from the same org/proj all have the same paths in objectstore regardless if the user passed in slugs or IDs.
There was a problem hiding this comment.
It might be weird to take in Api and it might be possible that these functions should live somewhere else, IDK.
They certainly don't belong to the Api struct as its methods seem to all map 1to1 to Sentry API calls.
There was a problem hiding this comment.
Can the backend interpret the slugs in to ids instead of the frontend?
There was a problem hiding this comment.
Can the backend interpret the slugs in to ids instead of the frontend?
Indeed, I agree that this would be preferable. The current code adds two additional API calls that could be avoided if the backend resolves the slugs/IDs appropriately.
There was a problem hiding this comment.
Not sure what backend and frontend here refers to.
How objectstore works is that the scope (org and project in this case) is an arbitrary sequence of key-value pairs. We recommend using org and project ID, or at least org ID, but that's not mandatory.
Therefore it's not a responsibility of objectstore or its endpoint in the monolith to normalize org and project, we simply take what the user provides. It's responsibility of the user to normalize.
| lazy_static = "1.4.0" | ||
| libc = "0.2.139" | ||
| log = { version = "0.4.17", features = ["std"] } | ||
| objectstore-client = { git = "https://github.com/getsentry/objectstore.git", branch = "lcian/feat/rust-batch-client" } |
There was a problem hiding this comment.
This indirectly adds a dependency to reqwest and we need to double check what the implications of that are, especially in regard to rustls vs native-tls which could be problematic.
There was a problem hiding this comment.
It also adds a bunch of deps but I think most of them are inevitable.
There was a problem hiding this comment.
Let's discuss the TLS stuff next week, because I am uncertain what problems you're concerned about.
| let client = Client::new(url)?; | ||
|
|
||
| let (org, project) = get_org_project_id(Api::current(), org, project)?; | ||
| let session = Usecase::new("preprod") |
There was a problem hiding this comment.
We should set an expiration policy here.
I think based on our discussions TTL should be ideal for this usecase?
There was a problem hiding this comment.
As we discussed we want different TTL based on customer/plan. We could introduce a new endpoint in sentry that tells you this info and set the TTL here based on that.
There was a problem hiding this comment.
Yep, for now I think we're good with nothing set just for testing, but I'll track this here for my team to follow up on in the near future: https://linear.app/getsentry/issue/EME-839/endpoint-for-determining-ttl-for-an-org
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 3 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
src/commands/build/snapshots.rs
Outdated
| // For other files, use {org}/{project}/{hash} | ||
| let hash = compute_sha256_hash(&contents); | ||
| format!("{org}/{project}/{hash}") | ||
| }; |
There was a problem hiding this comment.
JSON file keys missing project ID causes cross-project collisions
High Severity
JSON file keys use the format {org}/{snapshot_id}/{filename} which excludes the project ID, while non-JSON files use {org}/{project}/{hash} which includes it. Since the command requires --project and is documented as uploading "build snapshots to a project", omitting the project ID from JSON file keys causes different projects within the same organization to overwrite each other's files when using the same snapshot_id and filename.
There was a problem hiding this comment.
I'll handle this and other business logic related to the emerge snapshot features
src/commands/build/snapshots.rs
Outdated
| files.push(entry_path.to_path_buf()); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Hidden directories not skipped, exposing sensitive files
Medium Severity
The WalkDir traversal descends into hidden directories (e.g., .git, .svn, .env.d/) but is_hidden_file only checks if the file's own name starts with .. Files inside hidden directories with non-hidden names (like .git/config, .git/objects/*) are uploaded despite the intent to skip hidden content. This could inadvertently upload sensitive data or significantly bloat uploads with unwanted files.
Additional Locations (1)
src/commands/build/snapshots.rs
Outdated
| .file_name() | ||
| .and_then(|name| name.to_str()) | ||
| .unwrap_or("unknown.json"); | ||
| format!("{org}/{snapshot_id}/{filename}") |
There was a problem hiding this comment.
JSON files in subdirectories with same filename overwrite each other
Medium Severity
For JSON files, the key is generated using only file_name() which extracts just the base filename, discarding any subdirectory path. If a user uploads a directory containing subdir1/data.json and subdir2/data.json, both files produce the identical key {org}/{snapshot_id}/data.json, causing the second file to silently overwrite the first and resulting in data loss.
|
Hey @lcian, are you ready for me to review this, or are you still planning to check the feedback from Bugbot and/or iterate further? |
Adds the initial snapshots POST API. This api does a few things and is intended to be invoked by the CLI: - Creates `PreprodArtifact`, `PreprodSnapshotMetrics` and `CommitComparison` DB models - Creates image metadata based on what's uploaded from CLI - Stores metadata in objectstore Notably images are uploaded directly to objectstore from CLI Tested E2E locally with objectstore and WIP CLI branch (getsentry/sentry-cli#3110) Resolves EME-773
Adds the initial snapshots POST API. This api does a few things and is intended to be invoked by the CLI: - Creates `PreprodArtifact`, `PreprodSnapshotMetrics` and `CommitComparison` DB models - Creates image metadata based on what's uploaded from CLI - Stores metadata in objectstore Notably images are uploaded directly to objectstore from CLI Tested E2E locally with objectstore and WIP CLI branch (getsentry/sentry-cli#3110) Resolves EME-773
There was a problem hiding this comment.
I left some comments. Most of them are minor and optional, but I would call your attention to the comment about memory usage and the potential for leaking tokens.
Let's discuss further next week
| #[derive(Deserialize, Debug)] | ||
| pub struct OrganizationLinks { | ||
| #[serde(rename = "regionUrl")] | ||
| pub region_url: String, | ||
| } |
There was a problem hiding this comment.
nit: you can use rename_all to avoid duplicating the field name
| #[derive(Deserialize, Debug)] | |
| pub struct OrganizationLinks { | |
| #[serde(rename = "regionUrl")] | |
| pub region_url: String, | |
| } | |
| #[derive(Deserialize, Debug)] | |
| #[serde(rename_all = "camelCase")] | |
| pub struct OrganizationLinks { | |
| pub region_url: String, | |
| } |
| #[derive(Deserialize, Debug)] | ||
| pub struct OrganizationDetails { | ||
| pub id: String, | ||
| pub links: OrganizationLinks, |
There was a problem hiding this comment.
If I understand correctly I think this information might already be somehow embedded in org tokens, but not in personal tokens
This is 100% correct
| #[derive(Deserialize)] | ||
| struct CreateSnapshotResponse { | ||
| #[serde(rename = "artifactId")] | ||
| artifact_id: String, | ||
| #[serde(rename = "imageCount")] | ||
| image_count: u64, | ||
| } |
There was a problem hiding this comment.
l:
| #[derive(Deserialize)] | |
| struct CreateSnapshotResponse { | |
| #[serde(rename = "artifactId")] | |
| artifact_id: String, | |
| #[serde(rename = "imageCount")] | |
| image_count: u64, | |
| } | |
| #[derive(Deserialize)] | |
| #[serde(rename_all = "camelCase")] | |
| struct CreateSnapshotResponse { | |
| artifact_id: String, | |
| image_count: u64, | |
| } |
| // Build manifest from discovered images | ||
| let mut manifest = json!({ | ||
| "app_id": app_id, | ||
| "images": {}, | ||
| }); |
There was a problem hiding this comment.
m: Why is this being custom-constructed as a JSON object?
I think it might make more sense to make a dedicated struct type for this manifest. Is there any reason why this was not done?
| let images_obj = manifest["images"] | ||
| .as_object_mut() | ||
| .expect("images object was just created"); | ||
| for image in &images { | ||
| images_obj.insert( | ||
| image.hash.clone(), | ||
| json!({ | ||
| "file_name": image.relative_path, | ||
| "width": image.width, | ||
| "height": image.height, | ||
| }), | ||
| ); | ||
| } |
There was a problem hiding this comment.
l: Following from my comment above, if we make a struct Manifest, this logic could be an implementation on the struct.
| lazy_static = "1.4.0" | ||
| libc = "0.2.139" | ||
| log = { version = "0.4.17", features = ["std"] } | ||
| objectstore-client = { git = "https://github.com/getsentry/objectstore.git", branch = "lcian/feat/rust-batch-client" } |
There was a problem hiding this comment.
Let's discuss the TLS stuff next week, because I am uncertain what problems you're concerned about.
| lazy_static = "1.4.0" | ||
| libc = "0.2.139" | ||
| log = { version = "0.4.17", features = ["std"] } | ||
| objectstore-client = { git = "https://github.com/getsentry/objectstore.git", branch = "lcian/feat/rust-batch-client" } |
There was a problem hiding this comment.
h: Before we merge these changes, we should ensure we are depending on a version that's been published to crates.io, not a Git branch.
| }; | ||
|
|
||
| let url = get_objectstore_url(Api::current(), org)?; | ||
| let client = ClientBuilder::new(url.clone()) |
There was a problem hiding this comment.
l: clone() appears to be unnecessary
| let client = ClientBuilder::new(url.clone()) | |
| let client = ClientBuilder::new(url) |
There was a problem hiding this comment.
l: I would move this to src/utils/api.rs for now
There was a problem hiding this comment.
l: Would move to src/utils/objectstore.rs for now.



Updated version of #3049 to discuss and iterate on things.
Notable changes:
shard_indexparameter from the command. I'm not sure what the purpose of that was originally.many(batch) API fromobjectstore_client. All uploads are executed as batch requests, reducing network overhead. Unfortunately, with they way things are implemented now, we will still have to buffer all files in memory before sending the request, as we need to hash their contents to determine the filename. If we could just use the filename as the key in objectstore, it would be much better because that way we could stream the files over.Note that auth enforcement still needs to be enabled for objectstore, so that's currently blocking this to be used for anything but internal testing.
Ref FS-233